Sources/StreamChatSwiftUI/ChatMessageList/Reactions/ReactionsOverlayView.swift (1)

86-91: Dismiss-on-empty-space fix looks correct.

Adding .contentShape(Rectangle()) + .onTapGesture to the Color.clear inside the GeometryReader is what actually makes the empty area dismiss the overlay — Color.clear already participates in hit-testing in SwiftUI, which is why taps there were previously being swallowed silently.

One small note: since this Color.clear fills the entire GeometryReader and sits above backgroundView in the outer ZStack, the pre-existing .onTapGesture on backgroundView (around line 196) is effectively shadowed for most of the screen. Not a functional issue, just potentially dead-ish code you could prune in a follow-up.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@Sources/StreamChatSwiftUI/ChatMessageList/Reactions/ReactionsOverlayView.swift`
around lines 86 - 91, The empty-area-dismiss behavior was added by making the
Color.clear inside the GeometryReader participate in hit-testing via
.contentShape(Rectangle()) and attach an .onTapGesture that calls
dismissReactionsOverlay; keep this change but remove or consider pruning the
now-shadowed .onTapGesture on backgroundView (inside the outer ZStack) since the
Color.clear covers most of the screen and renders that handler dead code—update
or delete the backgroundView's tap handler to avoid redundancy and ensure
dismissReactionsOverlay remains the single tap-to-dismiss entrypoint.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

Sources/StreamChatSwiftUI/ChatMessageList/MessageItemView.swift (1)

214-232: Minor: branching @ViewBuilder changes view identity based on shownAsPreview.

Because the two branches return structurally different view trees (one with gestures attached, one without), SwiftUI will treat them as different view identities if shownAsPreview ever toggled at runtime, discarding gesture/animation state. It's initialized once and effectively constant for a given MessageItemView, so this is safe today — just noting it as a latent pitfall if shownAsPreview ever becomes reactive. An equivalent and slightly safer pattern would be to always attach the gestures with including: gated on shownAsPreview, similar to what MessageContainerView does for its tap swallow.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@Sources/StreamChatSwiftUI/ChatMessageList/MessageItemView.swift` around lines
214 - 232, The current `@ViewBuilder` body(content:) in MessageItemView returns
different view trees when shownAsPreview toggles (one branch without gestures
and one with gestures), which can change view identity; instead always attach
the gestures to the content and gate their actions on shownAsPreview so the view
structure remains constant. Concretely, keep the onTapGesture and
highPriorityGesture(LongPressGesture(minimumDuration: longPressMinimumDuration))
on the content unconditionally, but inside their closures first check
shownAsPreview (and isDoubleTapEnabled for the double-tap) and return early if
preview mode is active; still call onActionsTriggered() only when allowed. This
change should be made in the body(content:) function of MessageItemView
(affecting the onTapGesture, isDoubleTapEnabled, longPressMinimumDuration,
LongPressGesture and onActionsTriggered references).

Sources/StreamChatSwiftUI/CommonViews/NukeImageLoader.swift (1)

27-55: Test hook implementation looks good.

The early-return in cachedResult and the nonisolated(unsafe) storage are appropriate for a test-only synchronous resolver that defaults to nil in production. One small organizational nit: the // MARK: - Test Hook section is interleaved between cachedResult and storeCachingKey, which slightly fragments the public cache-lookup API. Moving the hook declaration to the end of the type (near the // MARK: - Private section) would keep the public lookup/store pair together. Non-blocking.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@Sources/StreamChatSwiftUI/CommonViews/NukeImageLoader.swift` around lines 27
- 55, Move the test-only hook declaration nonisolated(unsafe) static var
testSyncLookup out of the middle of the public cache API so cachedResult and
storeCachingKey remain adjacent; specifically, remove the // MARK: - Test Hook
block from between cachedResult(...) and storeCachingKey(...) and reinsert the
testSyncLookup declaration at the end of the type near the // MARK: - Private
section to keep the public lookup/store pair together.

Sources/StreamChatSwiftUI/ChatMessageList/MessageMediaAttachmentContentView.swift (1)

118-128: Use .task(id:) for video thumbnail loading instead of onAppear guard.

The current onAppear { guard videoPreview == nil else { return } … } pattern has two issues:

1. Stale thumbnail on source change: If the view position is reused with a different source.url (which can happen when the items array is reshaped), videoPreview retains the old attachment's cached image and loading is skipped.

2. Retry re-triggering: After a failed load, videoPreviewError is set but videoPreview remains nil. Each re-appearance fires onAppear again, re-invoking loadVideoThumbnail() and potentially racing with a user-initiated retry tap.

Switching to .task(id: source.url) ties the load to the URL, re-runs on URL changes, and auto-cancels on view disappear. To support manual retry, add a videoRetryToken and include it in the task id, then have the retry overlay bump the token instead of calling loadVideoThumbnail() directly—mirroring the imageRetryToken pattern already in use.

♻️ Sketch

+    `@State` private var videoRetryToken = 0
+
     `@ViewBuilder`
     private var videoThumbnail: some View {
         ZStack {
             videoBackground
             videoOverlays
         }
-        .onAppear {
-            guard videoPreview == nil else { return }
-            loadVideoThumbnail()
-        }
+        .task(id: VideoLoadID(url: source.url, retry: videoRetryToken)) {
+            videoPreview = nil
+            loadVideoThumbnail()
+        }
     }

…and have the retry button in videoOverlays bump videoRetryToken &+= 1 instead of calling loadVideoThumbnail() directly.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@Sources/StreamChatSwiftUI/ChatMessageList/MessageMediaAttachmentContentView.swift`
around lines 118 - 128, Replace the onAppear guard-based loading in the
videoThumbnail View with a .task(id: ...) driven task that depends on the
attachment's source.url and a videoRetryToken so thumbnail loading re-runs when
the URL changes or a manual retry is triggered; specifically, remove the
onAppear { guard videoPreview == nil ... loadVideoThumbnail() } pattern in
videoThumbnail and instead invoke loadVideoThumbnail() inside .task(id:
(source.url, videoRetryToken)), add a videoRetryToken Int state (mirroring
imageRetryToken) and change the retry button in videoOverlays to bump
videoRetryToken (e.g., += 1) rather than calling loadVideoThumbnail() directly,
leaving existing videoPreview and videoPreviewError handling intact.